.env.example (1)

9-11: Minor formatting nits from static analysis.

The static analysis tool flagged two minor issues:

1. Key ordering: NEXT_PUBLIC_SUPABASE_ANON_KEY should come before NEXT_PUBLIC_SUPABASE_URL alphabetically
2. Missing blank line at the end of the file

These are low-priority style nits. The important thing is that GEMINI_API_KEY correctly lacks the NEXT_PUBLIC_ prefix, ensuring it remains server-side only.

💅 Optional fix for linter warnings

-NEXT_PUBLIC_SUPABASE_URL=http://localhost:1234
-NEXT_PUBLIC_SUPABASE_ANON_KEY=local-testing-key
+NEXT_PUBLIC_SUPABASE_ANON_KEY=local-testing-key
+NEXT_PUBLIC_SUPABASE_URL=http://localhost:1234

 GEMINI_API_KEY=your_api_key_here
+

src/components/courses/compare/CourseSelector.tsx (2)

3-3: Remove unused import.

useEffect is imported but not used in this component.

🧹 Remove unused import

-import { useState, useEffect } from 'react';
+import { useState } from 'react';

---

69-74: Consider adding accessible label to the remove button.

The remove button uses only an icon (X), which may not be accessible to screen readers. Adding an aria-label improves accessibility.

♿ Proposed fix for accessibility

               <button
                 onClick={() => handleRemoveCourse(course.id)}
                 className="ml-1 hover:text-destructive transition-colors"
+                aria-label={`Remove ${course.code} from comparison`}
               >
                 <X className="h-3 w-3" />
               </button>

src/components/courses/CompareCoursesButton.tsx (2)

36-38: Consider replacing alert() with a more polished notification.

Using alert() blocks the UI thread and provides a jarring UX. Consider using a toast notification component for a more seamless experience, especially since this is a user-facing action.

---

9-9: Centralize STORAGE_KEY to avoid drift.

The STORAGE_KEY constant is duplicated across three comparison-related components: CompareCoursesButton.tsx, CompareButton.tsx, and AddToComparison.tsx, all with the same value ('course_comparison_list'). Moving this to src/constants (which already exists in the codebase) would prevent accidental mismatches if the key name needs to change.

src/app/api/extract-themes/route.ts (2)

6-6: Remove unused courseCode from destructuring.

courseCode is extracted from the request body but never used in the route handler. Either remove it or use it (e.g., in logging or the prompt for additional context).

🧹 Proposed fix

-    const { courseId, courseCode } = await request.json();
+    const { courseId } = await request.json();

---

16-22: Consider adding rate limiting or caching for this endpoint.

This endpoint fetches reviews and calls an external AI API on every request. For popular courses, this could lead to:

1. Excessive Supabase queries
2. High Gemini API costs
3. Rate limiting from Google

Consider caching the extracted themes (e.g., in Supabase or Redis) with a TTL, and only regenerating when reviews are updated.

src/components/courses/course_page/CourseKeyThemes.tsx (2)

24-56: Missing loading state initialization before fetch.

Line 27 sets setIsLoading(true), but the initial state on Line 21 already sets isLoading to true. This is fine for the initial mount but causes a brief flash if re-fetching. Also, courseCode is included in the dependency array but isn't validated before calling the fetch.

Consider simplifying: either remove Line 27 (redundant on mount) or validate both props:

🔧 Suggested improvement

-    if (courseId) {
+    if (courseId && courseCode) {
       fetchKeyThemes();
     }

---

30-36: Consider using GET instead of POST for data retrieval.

This endpoint fetches data without side effects, which aligns better with GET semantics. Using POST for read-only operations can cause issues with caching and doesn't follow REST conventions. If POST is required for payload size reasons, this is acceptable but worth documenting.

src/components/courses/CompareButton.tsx (1)

62-65: Replace alert() with toast notifications.

Using alert() blocks the main thread and provides poor UX. Consider using a toast notification system (if available in your UI library) for a more polished experience.

Also applies to: 120-123

src/components/courses/compare/ReviewHighlights.tsx (2)

56-73: N+1 query pattern: Sequential fetches can be optimized.

The code fetches reviews for each course in a sequential loop, resulting in N database calls. This can be optimized by batching the query using .in('target_id', uuids) and then grouping results client-side.

♻️ Suggested optimization

-      // Fetch reviews for each course UUID
-      for (const course of courses) {
-        const uuid = codeToUUID[course.code.toUpperCase()];
-        if (!uuid) continue;
-
-        const { data, error } = await supabase
-          .from('reviews')
-          .select('id, comment, rating_value, difficulty_rating, workload_rating, created_at, target_id')
-          .eq('target_id', uuid)
-          .eq('target_type', 'course')
-          .not('comment', 'is', null)
-          .order('created_at', { ascending: false })
-          .limit(10);
-
-        if (!error && data) {
-          reviewsByUUID[course.id] = data;
-        }
-      }
+      // Batch fetch reviews for all course UUIDs
+      const uuids = Object.values(codeToUUID);
+      if (uuids.length === 0) {
+        setLoading(false);
+        return;
+      }
+
+      const { data: allReviews, error } = await supabase
+        .from('reviews')
+        .select('id, comment, rating_value, difficulty_rating, workload_rating, created_at, target_id')
+        .in('target_id', uuids)
+        .eq('target_type', 'course')
+        .not('comment', 'is', null)
+        .order('created_at', { ascending: false });
+
+      if (!error && allReviews) {
+        // Group by target_id and limit to 10 per course
+        const uuidToCourseId = Object.fromEntries(
+          courses.map(c => [codeToUUID[c.code.toUpperCase()], c.id])
+        );
+        for (const review of allReviews) {
+          const courseId = uuidToCourseId[review.target_id];
+          if (!courseId) continue;
+          if (!reviewsByUUID[courseId]) reviewsByUUID[courseId] = [];
+          if (reviewsByUUID[courseId].length < 10) {
+            reviewsByUUID[courseId].push(review);
+          }
+        }
+      }

---

140-147: Potential undefined value for Tabs defaultValue.

If courses[0]?.id is undefined (empty array case), the Tabs component may behave unexpectedly. While line 110 guards against empty courses, adding a fallback is safer.

🔧 Suggested fix

-          <Tabs defaultValue={courses[0]?.id} className="w-full">
+          <Tabs defaultValue={courses[0]?.id || ''} className="w-full">

src/app/courses/page.tsx (1)

5-7: Consider handling loading state for courses.

The useCourses hook returns { courses, isLoading, error }, but only courses is destructured. The ComparisonFloatingButton receives courses which may be empty while loading. Per the relevant code snippet for ComparisonFloatingButton, it returns null when no courses are selected, but the initial empty courses array during loading could cause brief UI inconsistencies.

This is a minor concern since the floating button handles empty selection gracefully, but for consistency with the comparison page (src/app/courses/compare/page.tsx lines 18, 22) which uses isLoading, you may want to handle the loading state here as well.

Also applies to: 19-19

src/components/courses/compare/ComparisonTable.tsx (1)

143-163: Consider using a stable key instead of array index.

Line 147 uses idx as the key for TableRow. While the comparisonRows array is stable within a render, using row.label as the key would be more semantically correct and resilient to future changes.

♻️ Suggested fix

-                  <TableRow
-                    key={idx}
+                  <TableRow
+                    key={row.label}
                     className="hover:bg-muted/30 transition-colors"
                   >

src/components/courses/compare/ComparisonCharts.tsx (2)

31-34: Remove unused getDepartmentColor function.

This helper function is defined but never used in this component. It appears to be copy-pasted from ComparisonTable.tsx. Consider removing it to reduce dead code.

♻️ Suggested fix

-  const getDepartmentColor = (department: string) => {
-    const dept = departmentProperties.find((d) => d.name === department);
-    return dept?.color || '#718096';
-  };
-

Also remove the unused import on line 20:

-import departmentProperties from '@/constants/department';

---

44-67: Remove unused idx parameter from reduce callbacks.

The idx parameter is declared but never used in the reduce callbacks. This is a minor cleanup.

♻️ Suggested fix

     {
       metric: 'Overall',
-      ...courses.reduce((acc, course, idx) => {
+      ...courses.reduce((acc, course) => {
         acc[course.code] = course.overall_rating;
         return acc;
       }, {} as Record<string, number>),
     },

Apply similar changes to the other reduce callbacks on lines 55 and 62.

docs/COURSE_COMPARISON_FEATURE.md (1)

163-163: Documentation claims memoization that isn't implemented.

The documentation states "Charts data is memoized to prevent unnecessary recalculations", but the ComparisonCharts.tsx component doesn't use useMemo for its data transformations (ratingsData, radarData, creditsData). Consider either implementing memoization or updating the documentation to be accurate.

CONTRIBUTION.md:72

• After adding GEMINI_API_KEY as item #5, the subsequent heading still says “### 5. Run Development Server”, which makes the numbering inconsistent. Renumber this section (and any subsequent references) to keep the setup steps clear.

5. GEMINI_API_KEY

This is your Google Gemini API key for AI-powered course summaries. Get it from [Google AI Studio](https://makersuite.google.com/app/apikey). This key is used server-side only and should never be exposed to the frontend.

### 5. Run Development Server
```bash
npm run dev

</details>



---

💡 <a href="/OpenLake/RateMyCourse/new/main/.github/instructions?filename=*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.

src/lib/check-db.ts-44-44 (1)

44-44: ⚠️ Potential issue | 🟠 Major

Avoid import-time execution for a service-role DB script.

Running checkDatabase() at import time can trigger unintended live DB calls and side effects. Export the function and invoke it from a dedicated CLI/script entrypoint instead.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/check-db.ts` at line 44, Remove the top-level invocation of
checkDatabase() so the module does not perform DB calls at import time; ensure
checkDatabase remains exported (export async function checkDatabase(...)) and
create a separate CLI/script entrypoint that imports checkDatabase, calls it,
awaits errors, logs failures and exits with non-zero status on error. Also
verify the module has no other side-effectful calls so importing it is safe for
service-role code.

src/lib/check-db.ts-4-7 (1)

4-7: ⚠️ Potential issue | 🟠 Major

Fail fast on missing Supabase env vars.

Using non-null assertions here can mask config issues and fail later with less actionable errors. Add explicit validation before creating the client.

Proposed fix

-const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL!;
-const supabaseServiceKey = process.env.SUPABASE_SERVICE_ROLE_KEY!;
+const supabaseUrl = process.env.NEXT_PUBLIC_SUPABASE_URL;
+const supabaseServiceKey = process.env.SUPABASE_SERVICE_ROLE_KEY;
+
+if (!supabaseUrl || !supabaseServiceKey) {
+  throw new Error(
+    'Missing required env vars: NEXT_PUBLIC_SUPABASE_URL and/or SUPABASE_SERVICE_ROLE_KEY'
+  );
+}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/check-db.ts` around lines 4 - 7, The code uses non-null assertions
for supabaseUrl and supabaseServiceKey which can hide missing config; before
calling createClient, explicitly validate process.env.NEXT_PUBLIC_SUPABASE_URL
and process.env.SUPABASE_SERVICE_ROLE_KEY (the variables assigned to supabaseUrl
and supabaseServiceKey), and if either is missing log a clear error and exit (or
throw) so the app fails fast; then pass the validated values to createClient to
construct supabase.

src/lib/check-db.ts-35-39 (1)

35-39: ⚠️ Potential issue | 🟠 Major

Handle reviews query errors before logging success.

Line 39 logs a success count even if the query fails. Please mirror the error handling used for professors/courses.

Proposed fix

-  const { count: reviewCount } = await supabase
+  const { count: reviewCount, error: reviewError } = await supabase
     .from('reviews')
     .select('*', { count: 'exact', head: true });
-  
-  console.log(`✅ Reviews: ${reviewCount || 0} records`);
+
+  if (reviewError) {
+    console.error('❌ Error checking reviews:', reviewError.message);
+  } else {
+    console.log(`✅ Reviews: ${reviewCount ?? 0} records`);
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/check-db.ts` around lines 35 - 39, The reviews query currently logs a
success count unconditionally; update the supabase.from('reviews') call that
returns { count: reviewCount } to also capture and check the returned error
(e.g., const { count: reviewCount, error: reviewsError } = await
supabase.from('reviews').select(...)); if reviewsError is truthy, call
processLogger.error (or console.error if consistent with professors/courses
handling) with the error and exit (process.exit(1)), otherwise log the count
with the existing message using reviewCount || 0.

docs/SETUP_GUIDE.md-9-12 (1)

9-12: ⚠️ Potential issue | 🟠 Major

Avoid hardcoded Supabase project URL in shared setup docs.

This points everyone to one specific instance. Use a placeholder (or .env variable reference) so contributors use their own project.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SETUP_GUIDE.md` around lines 9 - 12, Replace the hardcoded Supabase
project URL in the "Open your Supabase Dashboard" section with a placeholder or
environment variable reference (e.g., SUPABASE_URL or <your-supabase-url>) so
contributors use their own project; update the text under the heading "Open your
Supabase Dashboard" to instruct readers to insert their own Supabase dashboard
URL or refer to their .env variable instead of the specific URL currently shown.

setup.sh-23-27 (1)

23-27: ⚠️ Potential issue | 🟠 Major

Fail fast if migration inputs are missing before creating setup_database.sql.

The script currently assumes both SQL files exist; a missing file can produce a broken combined script and continue.

Proposed fix

 # Check if setup_database.sql exists
 if [ ! -f setup_database.sql ]; then
     echo "⚠️  Combined SQL file not found. Creating it..."
+    [ -f src/migrations/migration.sql ] || { echo "❌ Missing src/migrations/migration.sql"; exit 1; }
+    [ -f src/migrations/sentiment_analysis.sql ] || { echo "❌ Missing src/migrations/sentiment_analysis.sql"; exit 1; }
     cat src/migrations/migration.sql src/migrations/sentiment_analysis.sql > setup_database.sql
     echo "✅ Created setup_database.sql"
 fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@setup.sh` around lines 23 - 27, The script currently concatenates
src/migrations/migration.sql and src/migrations/sentiment_analysis.sql into
setup_database.sql without verifying the inputs; update the conditional block
that creates setup_database.sql to first check that both
src/migrations/migration.sql and src/migrations/sentiment_analysis.sql exist,
and if either is missing print a clear error identifying the missing file(s) and
exit with a non‑zero status so the script fails fast instead of producing a
broken combined file.

src/pages/api/ratings/route.ts-18-21 (1)

18-21: ⚠️ Potential issue | 🟠 Major

localhost fallback can break sentiment calls outside local dev.

Using process.env.NEXT_PUBLIC_BASE_URL || 'http://localhost:3000' makes background analysis fragile in deployed environments.

Proposed fix

-async function analyzeSentimentAsync(
+async function analyzeSentimentAsync(
+  origin: string,
   reviewId: string,
   comment: string,
   targetType: 'course' | 'professor'
 ): Promise<void> {
   try {
-    // Get the base URL for internal API calls
-    const baseUrl = process.env.NEXT_PUBLIC_BASE_URL || 'http://localhost:3000';
-    
-    const response = await fetch(`${baseUrl}/api/analyze-sentiment`, {
+    const response = await fetch(`${origin}/api/analyze-sentiment`, {
       method: 'POST',

-      analyzeSentimentAsync(data.id, sanitizedComment, targetType).catch((err) => {
+      const origin = new URL(request.url).origin;
+      analyzeSentimentAsync(origin, data.id, sanitizedComment, targetType).catch((err) => {
         console.error('Error in background sentiment analysis:', err);
         // Log error but don't fail the rating submission
       });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/api/ratings/route.ts` around lines 18 - 21, Replace the unsafe
localhost fallback: stop using process.env.NEXT_PUBLIC_BASE_URL ||
'http://localhost:3000' and instead require a real base URL (or derive it from
the incoming request) before calling fetch; update the code that sets baseUrl
(the baseUrl constant) so it either reads process.env.NEXT_PUBLIC_BASE_URL and
throws/logs an error if missing, or builds the URL from the current
request/origin, then use that baseUrl when calling
fetch(`${baseUrl}/api/analyze-sentiment`, ...) to avoid hardcoded localhost in
production.

setup.sh-17-17 (1)

17-17: ⚠️ Potential issue | 🟠 Major

Replace fragile .env parsing with safe shell loading.

export $(cat .env | ... | xargs) breaks on spaces/quotes and can mis-parse valid env values.

Proposed fix

+set -euo pipefail
+
 # Load environment variables
-export $(cat .env | grep -v '^#' | xargs)
+set -a
+# shellcheck disable=SC1091
+source .env
+set +a

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@setup.sh` at line 17, Replace the fragile export $(cat .env | ... | xargs)
line with a safe sourcing approach: check .env exists, enable automatic export
(allexport), source the .env file using a safe shell source (dot) to preserve
quoting/spaces, then disable automatic export; this avoids word-splitting and
preserves values — update the setup.sh snippet that contains the exact export
$(cat .env | grep -v '^#' | xargs) invocation accordingly.

src/pages/api/ratings/route.ts-153-160 (1)

153-160: ⚠️ Potential issue | 🟠 Major

Fire-and-forget promises can be interrupted in serverless request lifecycles.

The code uses .catch() on an unawaited promise, but this does not guarantee the sentiment analysis completes after the response is sent. Next.js Route Handlers do not keep the serverless invocation alive for unawaited tasks, especially on Vercel. For Next.js 13.5.1, consider:

• Using waitUntil() from @vercel/functions to extend the handler lifetime for post-response work
• Queueing the sentiment analysis via Vercel Queues or an external queue service
• Awaiting the task if timing allows

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/api/ratings/route.ts` around lines 153 - 160, The current
fire-and-forget call to analyzeSentimentAsync(data.id, sanitizedComment,
targetType) may be terminated in serverless lifecycles; replace the unawaited
.catch() pattern with a lifecycle-safe approach: call the Vercel waitUntil
handler (import waitUntil from '@vercel/functions') and pass the
analyzeSentimentAsync promise into waitUntil(...) so the runtime keeps the
invocation alive, or alternatively enqueue the sentiment job to your queue
service (e.g., Vercel Queues) instead of calling analyzeSentimentAsync directly;
update the code around analyzeSentimentAsync(...) to use waitUntil(...) or a
queue client send/enqueue method and keep error handling inside that
deferred/queued task.

src/app/api/batch-analyze-sentiment/route.ts-49-70 (1)

49-70: ⚠️ Potential issue | 🟠 Major

Missing timeout and retry logic (inconsistent with single-review route).

This batch route lacks the timeout and retry logic that exists in /api/analyze-sentiment. For batch operations where one failure shouldn't block the entire batch, at minimum add a timeout to prevent hanging on slow Gemini responses.

🛡️ Proposed fix with timeout

+  const controller = new AbortController();
+  const timeoutId = setTimeout(() => controller.abort(), 30000);
+
   const response = await fetch(
-    `https://generativelanguage.googleapis.com/v1beta/models/${SENTIMENT_CONFIG.gemini.model}:generateContent?key=${geminiApiKey}`,
+    `https://generativelanguage.googleapis.com/v1beta/models/${SENTIMENT_CONFIG.gemini.model}:generateContent`,
     {
       method: 'POST',
-      headers: { 'Content-Type': 'application/json' },
+      headers: {
+        'x-goog-api-key': geminiApiKey,
+        'Content-Type': 'application/json',
+      },
+      signal: controller.signal,
       body: JSON.stringify({
         // ... existing body
       }),
     }
   );
+
+  clearTimeout(timeoutId);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/api/batch-analyze-sentiment/route.ts` around lines 49 - 70, The batch
Gemini fetch call (the fetch(...) that assigns to response) needs timeout and
retry logic like the single-review route to avoid hanging or letting one
slow/failing call block the batch; wrap the fetch in an AbortController with a
configurable timeout (e.g., 5–10s) and add a retry loop with exponential backoff
(retry count 2–3) around the fetch call, and ensure failures for a single item
are caught and returned as an error result for that item rather than throwing
for the whole batch (update the code that constructs/handles response and any
per-item processing to tolerate and record individual timeouts/errors).

src/app/api/analyze-sentiment/route.ts-115-142 (1)

115-142: ⚠️ Potential issue | 🟠 Major

Missing timeout and API key in query parameter.

Similar to other Gemini API routes in this PR:

1. The API key is passed in the URL query parameter instead of the recommended x-goog-api-key header.
2. There's no timeout configured, which could cause the request to hang indefinitely if Gemini is slow.

🛡️ Proposed fix with timeout and header authentication

+    const controller = new AbortController();
+    const timeoutId = setTimeout(() => controller.abort(), 30000);
+
+    try {
       const response = await fetch(
-        `https://generativelanguage.googleapis.com/v1beta/models/${SENTIMENT_CONFIG.gemini.model}:generateContent?key=${geminiApiKey}`,
+        `https://generativelanguage.googleapis.com/v1beta/models/${SENTIMENT_CONFIG.gemini.model}:generateContent`,
         {
           method: 'POST',
           headers: {
+            'x-goog-api-key': geminiApiKey,
             'Content-Type': 'application/json',
           },
+          signal: controller.signal,
           body: JSON.stringify({
             // ... existing body
           }),
         }
       );
+      clearTimeout(timeoutId);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/api/analyze-sentiment/route.ts` around lines 115 - 142, The fetch
call that constructs the Gemini request (in route.ts where response = await
fetch(...)) must send the API key in the x-goog-api-key header instead of as a
URL query param and must use a timeout via AbortController to avoid hanging;
update the request to remove key=${geminiApiKey} from the URL, add
headers['x-goog-api-key'] = geminiApiKey alongside 'Content-Type', and wrap the
fetch with an AbortController that calls abort() after a configurable timeout
(use SENTIMENT_CONFIG.gemini.timeout or a reasonable default) and ensure you
clear the timeout once the response arrives.

src/lib/sentiment-utils.ts-139-145 (1)

139-145: ⚠️ Potential issue | 🟠 Major

This loop performs serialized N+1 queries.

Each review does an awaited DB call in sequence, which can become a latency bottleneck for larger batches.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/sentiment-utils.ts` around lines 139 - 145, The loop builds
reviewsWithoutSentiment by awaiting hasSentimentAnalysis(review.id) serially
causing N+1 latency; replace this with a concurrent approach—either
modify/replace hasSentimentAnalysis to accept an array of review IDs and perform
a single DB/batch query (preferred) or concurrently call hasSentimentAnalysis
for all reviews with Promise.all and then filter by the returned boolean array;
update the block that creates reviewsWithoutSentiment (the for loop and
hasSentimentAnalysis calls) and keep the existing check for review.comment &&
review.comment.length >= SENTIMENT_CONFIG.preprocessing.minCommentLength.

src/lib/__tests__/sentiment-analysis.test.ts-107-109 (1)

107-109: ⚠️ Potential issue | 🟠 Major

Valid comment case currently expects an impossible success path.

Line 107 sets reviewId: 'test-uuid', so a well-implemented API will return not found/validation error even with a valid comment. This makes the assertion misleading.

Also applies to: 115-118

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/__tests__/sentiment-analysis.test.ts` around lines 107 - 109, The
"Valid comment" test in src/lib/__tests__/sentiment-analysis.test.ts is
supplying a hardcoded reviewId ('test-uuid') which will cause the API to return
not-found/validation errors; update the test payload used in the "Valid comment"
case (and the similar block at the other failing case) to use a real review id
created earlier in the test setup or remove the reviewId field so the API can
accept the comment, ensuring the test asserts the successful sentiment response
from the handler (look for the test case name "Valid comment" and the object
with reviewId/comment/targetType to locate and fix).

src/migrations/sentiment_analysis.sql-135-136 (1)

135-136: ⚠️ Potential issue | 🟠 Major

aspect_sentiments aggregation is declared but never persisted.

aspect_avg is unused and the UPDATE statements never write aspect_sentiments, so that column stays stale/default.

Also applies to: 165-171, 216-222

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/migrations/sentiment_analysis.sql` around lines 135 - 136, The migration
computes an aggregated JSONB into the local variable aspect_avg (and similar
aggregates in the other blocks) but never persists it to the table, so
aspect_sentiments remains unchanged; modify the UPDATE statements that currently
reference aspect_avg to set the column (e.g., include "SET aspect_sentiments =
aspect_avg" or casted JSONB equivalent) after computing the aggregate, ensuring
the computed JSONB is written back for each relevant UPDATE/SELECT block that
declares aspect_avg and the other aggregates (the blocks around the declared
variable aspect_avg and the UPDATE statements that should write to
aspect_sentiments in those ranges).

setup_database.sql-10-16 (1)

10-16: ⚠️ Potential issue | 🟠 Major

Top-of-script cleanup is incomplete for a rerun path.

review_sentiments, related views, functions, and triggers are not dropped before dropping base tables, so rerunning this “clean migration” can fail on dependencies.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@setup_database.sql` around lines 10 - 16, Top-of-script cleanup fails to
remove dependent objects for reruns; before dropping base tables add explicit
DROP statements for the materialized/view/table "review_sentiments" and any
dependent views, functions and triggers (or use DROP ... IF EXISTS ... CASCADE)
so dependencies are removed first; specifically, call DROP VIEW/MATERIALIZED
VIEW IF EXISTS review_sentiments, DROP FUNCTION IF EXISTS <function names>(),
DROP TRIGGER IF EXISTS <trigger names> ON <table>, or simply DROP TABLE/VIEW ...
CASCADE before executing the existing DROP TABLE IF EXISTS
users/courses/professors/... sequence.

src/migrations/sentiment_analysis.sql-15-16 (1)

15-16: ⚠️ Potential issue | 🟠 Major

overall_sentiment type conflicts with decimal thresholds used elsewhere.

This schema stores integers only, but the feature logic/docs/tests use values like 4.5 and threshold boundaries at 4.5/3.5/2.5.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/migrations/sentiment_analysis.sql` around lines 15 - 16, The
overall_sentiment column is currently INTEGER which prevents storing decimal
values like 4.5 used elsewhere; change the column definition for
overall_sentiment to a numeric type that supports one decimal place (e.g.,
NUMERIC(2,1) NOT NULL) and keep or adjust its CHECK constraint to allow decimal
bounds (e.g., CHECK (overall_sentiment BETWEEN 1.0 AND 5.0)) so the DB schema
matches the feature/tests that use thresholds like 4.5/3.5/2.5; update the
definition in the migration where overall_sentiment is declared.

src/lib/__tests__/sentiment-analysis.test.ts-163-176 (1)

163-176: ⚠️ Potential issue | 🟠 Major

Database trigger test mutates persistent data without cleanup.

This upsert writes to a real review_sentiments row and can alter aggregate sentiment permanently in shared/staging DBs.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/__tests__/sentiment-analysis.test.ts` around lines 163 - 176, The
test currently upserts into the real review_sentiments table via
supabaseAdmin.from('review_sentiments').upsert(...), which mutates persistent DB
state; change the test to avoid persistent writes by either wrapping the upsert
in a DB transaction and rolling it back, or by inserting then deleting the row
in a finally block. Concretely, capture the returned primary key from
supabaseAdmin.from('review_sentiments').upsert(...) (or .insert(...).select())
and ensure you call supabaseAdmin.from('review_sentiments').delete().eq('id',
returnedId) in a finally/afterEach to clean up, or replace the call with a
mocked supabaseAdmin client for this test so no real writes occur. Ensure
references to supabaseAdmin, upsert, and the review_sentiments table are updated
accordingly.

setup_database.sql-529-556 (1)

529-556: ⚠️ Potential issue | 🟠 Major

review_sentiments table must have RLS enabled to match the security model applied to all other tables.

All other tables (users, courses, professors, reviews, votes, flags) have RLS explicitly enabled at lines 346–352, but the review_sentiments table created at lines 529–556 lacks RLS enablement. The RLS ALTER statement at line 881 and policy statements at lines 882–887 are commented out.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@setup_database.sql` around lines 529 - 556, The review_sentiments table lacks
Row-Level Security; enable RLS for review_sentiments by adding an ALTER TABLE
... ENABLE ROW LEVEL SECURITY and then create the same per-role policies used
for the other tables (e.g., the policies that allow owners and privileged roles
to SELECT/INSERT/UPDATE/DELETE) so review_sentiments follows the same access
model as users, courses, professors, reviews, votes, and flags; ensure the
policy names and predicates mirror the existing ones applied to reviews (attach
policies covering owner-based access via review_id and any admin/system bypass
rules) and remove/commented-out placeholder policy statements so RLS is active
and enforced.

src/types/sentiment.ts-7-7 (1)

7-7: ⚠️ Potential issue | 🟠 Major

Type definition does not support decimal scoring used throughout the codebase.

SentimentScore restricts values to integers (1-5), but sentiment-config.ts defines thresholds at decimal boundaries (4.5, 3.5, 2.5, 1.5), and sentiment-utils.ts::getSentimentLabel() implements decimal-based classification logic. Mock data in tests and features consistently use decimal ratings (e.g., 4.5, 4.8, 3.8). Additionally, sentimentScoreToLabel() (lines 232-237) uses integer thresholds incompatible with getSentimentLabel().

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/types/sentiment.ts` at line 7, SentimentScore is too narrow (only
integers) and doesn't match decimal thresholds in sentiment-config.ts or the
decimal logic in sentiment-utils.ts::getSentimentLabel(); change the
SentimentScore type from the integer union to a numeric type (e.g., export type
SentimentScore = number) and update any annotations/usages accordingly, and
unify classification logic by updating sentimentScoreToLabel to use the same
decimal boundaries as getSentimentLabel (or delegate to getSentimentLabel) so
thresholds (4.5, 3.5, 2.5, 1.5) are applied consistently across the codebase.

src/lib/sentiment-utils.ts-35-41 (1)

35-41: ⚠️ Potential issue | 🟠 Major

Server-side fallback to http://localhost:3000 is unsafe in production without NEXT_PUBLIC_BASE_URL configured.

When triggerSentimentAnalysis runs server-side (via getReviewsNeedingAnalysis batch processing) without NEXT_PUBLIC_BASE_URL set in the environment, it defaults to localhost and fails. The same pattern is repeated in src/pages/api/ratings/route.ts. Additionally, NEXT_PUBLIC_BASE_URL is missing from .env.example, leaving no guidance for developers to configure this required variable in production.

Either require the environment variable explicitly or add it to .env.example with clear documentation that it must be set for production deployments.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/sentiment-utils.ts` around lines 35 - 41, The server-side code (e.g.,
in triggerSentimentAnalysis and getReviewsNeedingAnalysis where you build
baseUrl for fetch to /api/analyze-sentiment) currently falls back to
'http://localhost:3000' when NEXT_PUBLIC_BASE_URL is not set, which is unsafe;
change the logic so that on the server (typeof window === 'undefined') you do
not default to localhost but instead require NEXT_PUBLIC_BASE_URL (throw a clear
error or fail-fast with a descriptive message) and use that value for the fetch
URL, and also add NEXT_PUBLIC_BASE_URL with guidance to .env.example so
developers know to configure it for production deployments.

src/migrations/sentiment_analysis.sql-11-11 (1)

11-11: ⚠️ Potential issue | 🟠 Major

Qualify uuid_generate_v4() function calls to ensure proper resolution across migration contexts.

uuid_generate_v4() is unqualified here and in migration.sql. Since extensions are created in the extensions schema (not public), if the database search_path doesn't include that schema, function lookup will fail. Use extensions.uuid_generate_v4() instead, as already done for extensions.gen_random_bytes() and extensions.digest() in migration.sql line 502–506.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/migrations/sentiment_analysis.sql` at line 11, The DEFAULT expression for
the id column uses an unqualified uuid_generate_v4() which can fail if the
extensions schema isn't in search_path; update the id column DEFAULT to call
extensions.uuid_generate_v4() instead (replace the unqualified
uuid_generate_v4() in the id UUID PRIMARY KEY DEFAULT ... definition), matching
how extensions.gen_random_bytes() and extensions.digest() are referenced
elsewhere.

docs/SETUP_GUIDE.md-10-12 (1)

10-12: ⚠️ Potential issue | 🟡 Minor

Add a language to the fenced block for markdown lint compliance.

Use something like ```text for the URL snippet.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SETUP_GUIDE.md` around lines 10 - 12, Update the fenced code block that
currently contains the Supabase URL (the triple backtick block showing
"https://nljwzmdeznmreaoffgxj.supabase.co") to include a language identifier
(e.g., use ```text or ```url) so the Markdown linter recognizes the block
language; simply change the opening fence to include the language token while
keeping the URL content unchanged.

docs/SETUP_COMPLETE.md-27-30 (1)

27-30: ⚠️ Potential issue | 🟡 Minor

Use repository-relative start instructions instead of a machine-specific absolute path.

cd /home/akshat/Openlake/RateMyCourse won’t work for other contributors.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SETUP_COMPLETE.md` around lines 27 - 30, Replace the machine-specific
absolute path in the setup instructions with a repository-relative step so
contributors can follow them on any machine; update the block that shows
changing directory and starting the dev server so it instructs users to change
into the repository root (or run the commands from the cloned repo) and then run
the existing npm run dev command instead of cd
/home/akshat/Openlake/RateMyCourse.

docs/SETUP_COMPLETE.md-120-120 (1)

120-120: ⚠️ Potential issue | 🟡 Minor

Fix heading typo.

“You'reAll Set!” should be “You’re All Set!”.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SETUP_COMPLETE.md` at line 120, Update the heading text "You'reAll Set!"
to the corrected form "You’re All Set!" in the file (replace the contiguous text
in the heading line), ensuring the spacing between "You're" and "All" is fixed
and the apostrophe uses the curly typographic form as shown.

docs/SENTIMENT_QUICK_REFERENCE.md-3-5 (1)

3-5: ⚠️ Potential issue | 🟡 Minor

Update phase/status wording to match the current implementation state.

The document still frames sentiment work as upcoming (“Week 2/Week 3”), but this PR includes implementation. This can mislead setup/testing expectations.

Also applies to: 349-362

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SENTIMENT_QUICK_REFERENCE.md` around lines 3 - 5, Update the status and
phase wording in SENTIMENT_QUICK_REFERENCE.md so it reflects that implementation
is included in this PR: change the header lines like "**Status**: Week 1 Design
Phase Complete ✅" and "**Next**: Week 2 Implementation Phase" (and any other
references to "Week 2/Week 3" in the sections around lines 349–362) to indicate
"Implementation in progress" or "Implementation complete" and update any
setup/testing notes to remove “upcoming” phrasing so readers know implementation
exists and how to run/tests the feature.

src/lib/verify-reviews.ts-10-34 (1)

10-34: ⚠️ Potential issue | 🟡 Minor

Missing error handling for null course and potential null comment access.

1. If MAL100 is not found, course will be null, causing the subsequent queries and logs to fail silently or produce confusing output.
2. Line 33 calls r.comment.substring(0, 100) but the reviews query doesn't filter out null comments, which will throw a runtime error.

🐛 Proposed fix

   const { data: course } = await supabase
     .from('courses')
     .select('id, code, title, review_count, overall_rating, difficulty_rating, workload_rating')
     .eq('code', 'MAL100')
     .single();

+  if (!course) {
+    console.error('❌ Course MAL100 not found');
+    return;
+  }
+
   console.log('\n📊 MAL100 Course Stats:');
   console.log('=======================');
-  console.log('Course:', course?.code, '-', course?.title);
-  console.log('Reviews:', course?.review_count);
-  console.log('Overall Rating:', course?.overall_rating, '⭐');
-  console.log('Difficulty:', course?.difficulty_rating, '/5');
-  console.log('Workload:', course?.workload_rating, '/5');
+  console.log('Course:', course.code, '-', course.title);
+  console.log('Reviews:', course.review_count);
+  console.log('Overall Rating:', course.overall_rating, '⭐');
+  console.log('Difficulty:', course.difficulty_rating, '/5');
+  console.log('Workload:', course.workload_rating, '/5');
   
   const { data: reviews } = await supabase
     .from('reviews')
     .select('rating_value, comment')
-    .eq('target_id', course?.id)
-    .eq('target_type', 'course');
+    .eq('target_id', course.id)
+    .eq('target_type', 'course')
+    .not('comment', 'is', null);
   
   console.log('\n📝 Sample Reviews:');
   reviews?.slice(0, 3).forEach((r, i) => {
     console.log(`\n${i + 1}. Rating: ${r.rating_value}⭐`);
-    console.log(`   "${r.comment.substring(0, 100)}..."`);
+    console.log(`   "${r.comment?.substring(0, 100) ?? '(no comment)'}..."`);
   });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/verify-reviews.ts` around lines 10 - 34, The code assumes course and
review comments are always present; add null checks and early exits: after
fetching course (variable course) verify it exists and if not log a clear
message and return/throw before using course.id or logging course fields; when
querying reviews only call .eq('target_id', course.id) if course is non-null.
For printing fields like course.review_count and ratings use safe access (or
fallback values) to avoid undefined output. For sample reviews, ensure reviews
is an array and guard comment access by using r.comment?.substring(0,100) or
defaulting r.comment to '' before substring to avoid runtime errors when comment
is null.

src/lib/sentiment-utils.ts-240-250 (1)

240-250: ⚠️ Potential issue | 🟡 Minor

Emotion color mapping is incomplete for configured emotions.

Values like inspired, motivated, indifferent, uncertain, calm, confused, and stressed all fall back to gray.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/sentiment-utils.ts` around lines 240 - 250, The emotionColors mapping
in sentiment-utils.ts is missing entries for several configured emotions causing
many values to fall back to gray; update the emotionColors Record<string,string>
(and any related mapping logic used by the function that returns
emotionColors[emotion.toLowerCase()]) to include keys for inspired, motivated,
indifferent, uncertain, calm, confused, stressed (and any other configured
emotions) with appropriate color values, and ensure the lookup still uses
emotion.toLowerCase() so the existing return statement (return
emotionColors[emotion.toLowerCase()] || 'gray') works as intended.

docs/SENTIMENT_BACKEND_IMPLEMENTATION.md-111-113 (1)

111-113: ⚠️ Potential issue | 🟡 Minor

Retry description and formula are inconsistent.

Line 112 shows 1000ms * retry_count (linear backoff), but the text says exponential backoff.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SENTIMENT_BACKEND_IMPLEMENTATION.md` around lines 111 - 113, The retry
description is inconsistent: update the documentation so the backoff formula
matches the claimed exponential behavior; either change the formula line
currently reading "Delay: 1000ms * retry_count" to an exponential formula such
as "Delay: 1000ms * (2 ** (retry_count - 1))" or change the wording to "linear
backoff" to match the current formula—ensure the line under the retry policy and
the phrase "exponential backoff" are consistent.

docs/SENTIMENT_BACKEND_IMPLEMENTATION.md-214-219 (1)

214-219: ⚠️ Potential issue | 🟡 Minor

Fix invalid JSON in request example.

"targetType": "course" | "professor" is TypeScript-union syntax, not valid JSON, so copy/paste integrations will fail.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/SENTIMENT_BACKEND_IMPLEMENTATION.md` around lines 214 - 219, The example
JSON uses TypeScript union syntax for the "targetType" field which is invalid
JSON; update the example in SENTIMENT_BACKEND_IMPLEMENTATION.md to use a
concrete string value for "targetType" (e.g., "course" or "professor") or
provide two separate valid JSON examples showing each allowed value so
copy/paste integrations work; ensure the field name "targetType" remains
unchanged and only the value format is corrected.

src/types/sentiment.ts-123-130 (1)

123-130: ⚠️ Potential issue | 🟡 Minor

Remove the unused ratings field from AnalyzeSentimentRequest.

The ratings field is declared as mandatory in this type, but all callers omit it when sending requests (see triggerSentimentAnalysis in src/lib/sentiment-utils.ts line 46–50). The field is never used in the sentiment analysis logic. Either make it optional or remove it to align the type contract with actual usage.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/types/sentiment.ts` around lines 123 - 130, The AnalyzeSentimentRequest
type currently declares a mandatory ratings field that is never populated or
used; remove the ratings property from the AnalyzeSentimentRequest type
declaration to match actual usage (instead of making it optional), then update
any references to ratings (if any) and run the TypeScript build/typecheck to
ensure no remaining usages break (check triggerSentimentAnalysis in
src/lib/sentiment-utils.ts as a caller to confirm compatibility).

src/app/api/extract-themes/route.ts (1)

6-6: Unused courseCode parameter.

The courseCode is destructured from the request body but never used in the function. Consider removing it from the destructuring or using it in logging/the prompt for context.

♻️ Suggested fix

-    const { courseId, courseCode } = await request.json();
+    const { courseId } = await request.json();

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/api/extract-themes/route.ts` at line 6, The request body destructures
courseId and courseCode in the route handler (const { courseId, courseCode } =
await request.json();) but courseCode is unused; either remove courseCode from
the destructuring to avoid dead variable warnings or wire courseCode into the
logic (for example include it in the processLogger calls or incorporate it into
the prompt/context construction where courseId is used). Update the route
handler (the function that calls request.json()) accordingly so only used
parameters are kept or consumed.

src/app/api/batch-analyze-sentiment/route.ts (1)

14-17: Weak return type reduces type safety.

analyzeWithGemini returns Promise<any>, which loses type information. Consider defining a proper return type interface for better maintainability and IDE support.

♻️ Suggested fix

+interface GeminiSentimentResult {
+  overallSentiment: number;
+  overallConfidence: number;
+  aspectSentiments: Record<string, { score: number; confidence: number }>;
+  primaryEmotion: string | null;
+  emotionIntensity: number | null;
+  rawResponse: any;
+}

 async function analyzeWithGemini(
   comment: string,
   targetType: 'course' | 'professor'
-): Promise<any> {
+): Promise<GeminiSentimentResult> {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/api/batch-analyze-sentiment/route.ts` around lines 14 - 17, The
function analyzeWithGemini currently returns Promise<any>, losing type safety;
define a clear return interface (e.g., SentimentAnalysisResult with fields like
sentimentLabel, score, details, targetType) and replace Promise<any> with
Promise<SentimentAnalysisResult> in the analyzeWithGemini signature, update the
function body to construct and return that typed object, and update any callers
(e.g., functions that invoke analyzeWithGemini) to use the new type for proper
typing and IDE autocompletion.

src/app/api/analyze-sentiment/route.ts (1)

191-196: Backoff is linear, not exponential.

The retry delay uses retryDelay * retries, which produces linear backoff (e.g., 1s, 2s, 3s). For exponential backoff, use retryDelay * Math.pow(2, retries) (e.g., 1s, 2s, 4s).

♻️ Suggested fix for exponential backoff

       if (retries < SENTIMENT_CONFIG.gemini.retryAttempts) {
         // Wait before retrying
         await new Promise(resolve => 
-          setTimeout(resolve, SENTIMENT_CONFIG.gemini.retryDelay * retries)
+          setTimeout(resolve, SENTIMENT_CONFIG.gemini.retryDelay * Math.pow(2, retries))
         );
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/app/api/analyze-sentiment/route.ts` around lines 191 - 196, The retry
wait currently multiplies SENTIMENT_CONFIG.gemini.retryDelay by retries,
producing linear backoff; update the delay calculation in the retry block inside
src/app/api/analyze-sentiment/route.ts to use exponential backoff (e.g.,
multiply retryDelay by Math.pow(2, retries) or 2 ** retries) so the wait becomes
retryDelay * 2^retries; keep the existing condition (if (retries <
SENTIMENT_CONFIG.gemini.retryAttempts)) and the Promise/setTimeout structure but
replace the linear multiplier with the exponential one using the existing
retries and SENTIMENT_CONFIG.gemini.retryDelay identifiers.

src/lib/add-dummy-reviews.ts (1)

103-105: Fragile UUID generation pattern.

The dummy UUID pattern 00000000-0000-0000-0000-00000000000${i} only produces valid UUIDs for single-digit indices (0-9). If more reviews are added to the array, the UUID format would break (e.g., index 10 would produce ...00000000010 which is 13 characters instead of 12).

♻️ Suggested fix using padded indices

-          anonymous_id: `00000000-0000-0000-0000-00000000000${i}`, // Dummy UUIDs
+          anonymous_id: `00000000-0000-0000-0000-${String(i).padStart(12, '0')}`, // Dummy UUIDs

Or use crypto.randomUUID() for proper UUIDs:

anonymous_id: crypto.randomUUID(),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/add-dummy-reviews.ts` around lines 103 - 105, Replace the fragile
string-based anonymous_id generation inside the .insert({ ... }) call with a
proper UUID generator: use crypto.randomUUID() (or import randomUUID from
'crypto' and call randomUUID()) for each dummy review, e.g. replace the template
`00000000-...${i}` with crypto.randomUUID(); alternatively, if deterministic IDs
are required, generate a fixed-width padded index (i.toString().padStart(12,
'0')) and insert that as anonymous_id. Update the anonymous_id expression where
.insert({ anonymous_id: ... , target_id: course.id }) is used so all created
dummy IDs remain valid UUIDs or consistently padded identifiers.

src/lib/sentiment-config.ts (2)

247-251: AspectKey is course-only but named as if it were global.

This type excludes professor aspects and can create incorrect assumptions in shared utilities.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/sentiment-config.ts` around lines 247 - 251, The AspectKey type is
incorrectly scoped to SENTIMENT_CONFIG.aspects.course (so it excludes professor
aspects); change its definition to derive keys from the full aspects object
(e.g., use keyof typeof SENTIMENT_CONFIG.aspects or otherwise union the keys
from all aspect groups) so utilities using AspectKey reflect all aspect kinds;
update any usages of AspectKey if they assumed course-only semantics.

---

6-251: Add as const to SENTIMENT_CONFIG to enforce literal types for emotion values.

Without as const, the EmotionValue type resolves to string instead of a literal union, losing type strictness. While this doesn't currently affect the codebase (the type is exported but unused), adding as const improves type safety and would prevent issues if the type is consumed in the future.

Suggested fix

-export const SENTIMENT_CONFIG = {
+export const SENTIMENT_CONFIG = {
  ...
-};
+} as const;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/lib/sentiment-config.ts` around lines 6 - 251, The SENTIMENT_CONFIG
object is currently mutable so EmotionValue collapses to string; fix by making
SENTIMENT_CONFIG a readonly literal by adding "as const" to its declaration
(i.e., export const SENTIMENT_CONFIG = { ... } as const). This will preserve
literal types for nested emotion values and tighten the EmotionValue type; keep
the existing exported shortcuts (GEMINI_CONFIG, PREPROCESSING_CONFIG, etc.)
as-is since they will inherit readonly literal types from SENTIMENT_CONFIG.